AltME groups: search

in the current stat of the host-kit and rebol architecture in general:
---------------------------

1) I cannot use data, since that is being used by r3_gui.r3 so it 
has in effect become a reserved word which we can't use.

2) if I use gob/draw, then I am in fact trying to hijack the meaning 
 of  draw gob... an AGG draw block.

3) the current gob! API is very limited because it was shrunk to 
handle a very specific use case.  I can't really play around with 
anything cause it just breaks up real quick (I tried).

4) the CGR API doesn't have a scene dialect yet, but that is just 
high-level use.  if you look at the code, its 4 lines of code to 
have an openGL high-rez model viewable in a window... I hardly consider 
that bloat.

5) using commands to manage a real life scene with several thousand 
animated, deforming objects and scene changes, is a nice dream. it 
doesn't work in practice since just managing the thousands of blocks 
this requires ends up eating a way a sizeable part of the CPU and 
ram.  

6) data marshalling is heavy, REBOL datatype access is heavy, datatypes 
use A LOT of ram, and the GC is extremely intrusive,  CGRs solve 
all of this while still making the high-level interface easy as pie.

7) primitives are more than just dead weight they allow direct access 
to/from rebol and the CGR itself.  they are the *low* level interface 
which can be used directly or directed by the use of a dialect later. 
  the difference from AGG is that these structures are persistent 
for many reasons, which will be much clearer in the future.

8) CGRs are not only for 3d graphics, but for any rendering.  primitives 
are a generic container to access/construct any rendering engine 
in the same way. ie. all CGR will use the same core cgr dialect.

9) the code does support multiple cgr gobs, but it might have bugs... 
I didn't even try it yet... I was busy getting this stable and released 
asap.

10) The opengl-cgr currently doesn't integrate into the view compositing, 
since that instantly *kills* rebol.  I mean... totally.  500x500 
a 30fps... = 100% cpu just blitting graphics (not even opengl rendering). 
 opengl-cgr uses the container mode, which actually uses up a sub-window 
(like every single construct in windows) and allows system double 
buffering in that area.

11) CGRs are compatible with all other gobs, though they must be 
built to support the internal gfx pipeline by using the compositor 
or image rendering modes.  That is how I started and it was quickly 
obvious how un feasible it was for opengl.

12) rendering performances ARE very implementation specific. using 
show instead of cgr-refresh on the display loop will show a performance 
penalty anywhere from 10-1000% (depending on nested gob depth & size). 
 If I didn't create internal data for the models, the large tree 
example would run much slower, if I used commands to call every opengl 
call in the large tree example, it would likely take several seconds 
a frame even with hw support.

in the future:
----------------------------

-there will be (hopefully) a small number of changes to the host-kit 
which will allow 1, 2, 3 to be resolved in a more natural REBOL feel... 
this current implementation actually highlights those needs and you 
where quick to point them out  :-)

-concurrency requires a bit more sophisticated structures to prevent 
locks, using the current design I solve some (though not all, yet) 
of the requirements for true concurrency, and this directly relates 
to issues and/or decisions in 5, 6, 7 & 8

-my goal is to have a high-performance rendering engine which isn't 
bound by any inherent design incompatibilities between REBOL and 
optimised native code, especially if the engine has access to hardware 
in parralel to the interpreter.  when i look at all the current games 
out there and they slow down even using only compiled code and sometimes 
not even really complex scenes, I don't want to fall into the trap 
of adding an additional layer of slowness which is to have the interpreter 
doing the renderer's job.

-I'm not trying to make a "cool" rebol plugin... I am trying to make 
an engine which is optimisized to run within REBOL.  the idea being 
not to help out rebolers per say, but to attract people with rendering 
needs TO REBOL because it has a high-perfomance engine *built-in* 
to which you can graph any actual renderer (DX, OpenGL, video frame 
buffers, etc).
-did I mention I want to make an AGG CGR ?  ;-)

True, some people are complaining the device is uderpowered. Flash 
video will not play smoothly in fullscreen, apparently. I don't know 
if the comparison is valid, but the chip is a 330 MhZ ARM while that 
one of the five years old (?) Palm T3 was a 440MHZ ARM processor.

Gabriele - I did rather extensive read on the minimal config of the 
thing, and it is like that:


- we are looking for embedded solution, we are space limited for 
our device, so no place for external gfx card either

- forget 1080p, unless you are about to use monstroze performance 
CPU, which will be power hog in a kiosk system

- so - you have to use HW, which contains codecs directly - ATI 680G 
chipset is minimum, 780 or 790 is beeter. nVidia 8200 or 9400 (Ion 
platform), VIA S3 500 family, Intell Poulsbo chipset

- with above, you don't need so much powerfull CPU, dualCore Atom 
would be able to play your video

- this one page is a good reference - http://www.tomshardware.com/reviews/amd-780g-chipset,1785-3.html


We are still investigating the situation. We started our work for 
Windows, but would like to move to Linux in the long run instead. 
We want to use ffmpeg project, but we will have to see, if its playback 
somehow utilises HW acceleration, or not. We will also look into 
projects like mplayer and VLC. Another problem I read about is, that 
so called HW acceleration is not always utilised. E.g. H.264 is not 
so clearly defined as mpeg2, and hence there is already plenty of 
videos, which are in MKV container, H.264, but using some super-set 
of features, which will not be supported by HW acceleration anyway 
... so - lot's of work for us :-)

Brett - I received an error about an unknow codec from Quicktime 
too, but if I press the play button when it shows a black screen, 
the video starts with a good video and audio.

Anyone downloaded Cyphre's video yet ? .... I got it downloaded but 
cant play it ....?

Yes, I thought about using transcode in linux. It's a shame all the 
variations don't make MP4 use as smooth as it could be. e.g. on Linux 
Fedora4 I could only get audio+video for your experimental encoding 
(trips to rome .. BTW, what is the band playing the background music 
?) . For the other files I could only get video but no audio so I 
had to check it in windows XP SP1 (where latest quicktime  and media 
player wouldn't play them (quicktime said incompatible profile) but 
an old VLC release played them fine)

the new rebcode version, is several times faster than the old, i'm 
happy !,  and I did not convert the video emulation into rebcode 
yet  , so ,   I think that we will be able to play in a screen much 
larger while keeping fluidity.

Gabriele, I understand you. Mov might be technologically even superior. 
So I don't know if it is licencsing of Apple or ignorance of Windows 
probrammers, but - I just want to use one codeck pack - ffdshow for 
e.g. It is some 5 years I met some video, which was not able to work 
with it. Any player! But - quicktime is painfull exception! I don't 
want quicktime player! I want it to play with any player I choose. 
And it does not seem being so. So, I have also VNC, just to have 
such problems as getting sound, but not picture, etc. So - no mov 
for me.

For that matter, unless you support their existing web services that 
they already have their data or the data they already want in it, 
it won't matter. That means their existing webmail account and Flash 
video. If you can't play YouTube (and RedTube, ...) it won't matter.


People don't care about the underlying technology unless they are 
techs. If you make a REBOL browser so that you can do REBOL stuff, 
and then try to support the old web stuff thinking that people will 
try the REBOL stuff and find it to be better, you will be wrong. 
Most people won't be able to tell the difference, because it isn't 
the technology that matters, it is the content. If you have the best 
content available in the most convenient way, people will install 
your software to get at it, whatever your software is written in.

The on demand broadcast seems not dumpable as with the ultraverbose 
vlc -vvv rtsp://195.220.133.26:80/iStream/01_opening1.mov

I can see the video and see the "SETUP <url>/trackID=4" and PLAY 
RTSP commands while, with the dump parameters:  vlc rtsp://195.220.133.26:80/iStream/01_opening1.mov 
:demux=dump :demuxdump-file="01_opening1.mov"

the SETUP and PLAY don't work (actually they are not even tried) 
and I get 
VLC media player 0.8.6a Janus

[00000288] main input error: no suitable access module for `rtsp://195.220.133.26:80/iStream/01_opening1.mov'
[00000279] main playlist: nothing to play
I also tried some vlc scripting but with no success

Machinarium's PlayBook version mentioned on GDC:

http://unplugged.rcrwireless.com/index.php/20110302/devices/7239/we-play-with-the-playbook-at-gdc-video/


Unfortunately it requires to be in AVM2 bytecode (usingActionScript3) 
so I must rewrite the game :/  But I use REBOL to help me with the 
task and a nasty REBOL script to scale the game to the correct resolution 
1024x600.

This is a stream from a friend of mine http://www.ustream.tv/channel/freedom-of-information-2008-az


She is using UStream to do this.  I'm going to play with this, but 
it "seems" sort of perfect for the Video part of what we are doing.
you set your "Show time" and go!


But, I will only know after I have played with the incoing, and also 
tried broadcasting, and gotten feedback from a large group.

Again, this might be a Graham question: I'm still working with that 
video encoder which uses http to communicate. They have a .cgi script 
which downloads the recorded video file from the internal SD card 
to the requester. My problem is the content I receive is somehow 
different than the files which I can download via a browser and of 
course will not play. I still using your http-tools to GET/POST. 
My initial thought was that  data returned is somehow being translated. 
Any thoughts?